This PR implements "auth by default" by configuring global humaConfig.Security with BearerAuth and ApiKeyAuth, so any operation that doesn't explicitly override its Security field inherits the requirement. Public endpoints (health, login, OIDC flows, app images, public settings, environment pairing) correctly opt out with Security: []map[string][]string{}. Template read endpoints now intentionally require authentication by relying on global inheritance, confirmed by the new TestSetupAPIForSpec_TemplateReadRoutesProtected test. The settings model gains a new SettingVisibilityNonAdmin tier, surfacing only public- and authrequired-tagged fields to authenticated non-admin users.

Safe to merge — auth-by-default logic is correct and well-tested; only a naming convention P2 remains.

All remaining findings are P2 style suggestions (unexported function naming convention). The core security logic — global security inheritance, public endpoint opt-out, visibility tier filtering — is sound and covered by new tests.

backend/internal/huma/middleware/auth.go — naming convention; no functional issues.

1. backend/internal/huma/handlers/templates.go, line 199-209 (link)

   Redundant explicit security on template handlers

   The four template read handlers (listTemplates, getAllTemplates, getTemplate, getTemplateContent) now carry an explicit Security block that is byte-for-byte identical to the global API security set in huma.go. Because any operation that omits Security already inherits the global default via parseSecurityRequirements, these blocks add noise without changing behaviour. Removing them would reduce boilerplate and make future global-security changes automatic for these routes.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: backend/internal/huma/handlers/templates.go
   Line: 199-209
   
   Comment:
   **Redundant explicit security on template handlers**
   
   The four template read handlers (`listTemplates`, `getAllTemplates`, `getTemplate`, `getTemplateContent`) now carry an explicit `Security` block that is byte-for-byte identical to the global API security set in `huma.go`. Because any operation that omits `Security` already inherits the global default via `parseSecurityRequirements`, these blocks add noise without changing behaviour. Removing them would reduce boilerplate and make future global-security changes automatic for these routes.
   
   How can I resolve this? If you propose a fix, please make it concise.